Rationale

This PR does not simplify or restructure (much) the Python package code, but rather aims at highlighting module / class dependencies and showing off interfaces.

Some modules in the Speculos Python code has evolved fast lately, and without formal / explicit structure, it becomes hard to understand the code or the impact of changes.

I've started by typing the code, which is a huge help to explicit what's used where. In the meantime, mypy asserts my assumptions and helps revealing unexpected / strange things, circular dependencies and whatnot.

Second step was to extract interfaces from the code in a neutral place (most in the existing speculos.mcu.display module, some other in speculos.mcu.struct module, and a speculos.observer module) and try to change the code so that it relies more on the abstractions rather than concrete classes (that's basically a dependency inversion task, which will help simplifying intricate code).

I think the third step would be to then restructure the code so that the abstractions are stored in sensible place, and concrete classes are lighter and clearer. I'm not sure this step will be finished in this PR, as it may need more scrutiny and may take longer to merge than this one alone (and the bigger the PR, the more painful the rebasing).

Current changes are:

CI changes

• Independent Python CI with flake8 (existed already), + mypy and bandit (this last is neutralized and will not redify the CI, although its output is interesting)
• Changed the reusable workflow so that the Speculos image is built once and not for each device

Code

Typing

Adding as much typing hints as possible, slightly modifying the code to add clarity

Architecture

• ObserverInterface and BroadcastInterface explicit an observer design pattern used through the AutomationServer and the EventsBroadcaster, and instantiated in the main function. The first one is tagged as legacy, so I suggest it should be cleaned for the next stable version. For now, the new interface helps keeping track of the current usage
• Added a GraphicalLibrary interface for both Bagl and NBGL in order to ease their usage. Direct usage of either bagl or nbgl in the seproxyhal module should not occur, they should be hidden inside the screen (a Display implementation). It is not done currently, it may require more work, but at least GraphicalLibrary covers some FrameBuffer methods, so that there is no longer code like screen.nbgl.m.take_screenshot(), but instead screen.gl.take_screenshot(), with gl being a generic type (GraphicalLibrary, so either Bagl or NBGL).
  Unfortunately, as some SephTags are NBGL-specifics, the dispatcher in SeProxyHal.can_read uses assert isinstance(screen.gl, NBGL) which degrades a bit the abstraction.
• The Display interface is used by TextScreen, Headless and Screen, however these implementation are not used consistently as the latter is shadowed by QtScreen which uses Screen through indirect composition. mypy clearly sees the issue, however the code is quite intricate here so not sure I'll flatten the dependencies here. => this has been answered in the last bullet of this list
• This Display interface also implements a sort of unclear observer design pattern too through its notifiers property and methods. I've started to define an interface IODevice for these notified classes (often defined as klass), they seem to be related to instances stored into ServerArgs but I've not yet catched the meaning of this.
• Back on the Display shenanigans, there is a very unclear way of managing the application graphic interfaces. There currently is 3 options: Text, Headless and Qt. The two firsts are quite similar, the last however, is very different and more complex. These classes are intertwined with the (now called) IODevice objects, and QtObject for the Qt one, with cross-dependencies all over the place (things like the notifiers and IODevice.can_read(klass)). First step I found there was to cut these classes in two: a DisplayNotifier, managing the event notifications, and a Display, used by the IODevices to interract with the screen. This way, the interfaces are clear: the main.py instantiates a DisplayNotifier and run its loop, and this DisplayNotifier can internally instantiate the correct Display and notify the IODevice. This is to be improved yet, but still sounds better than previously, where the QtScreen was really not on the same level as the others (Headless and TextScreen).